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(54) Method and system for using a sync key 

(57) A method and system for synchronization of da- 
ta stores is described. A synchronization initiator sends 
a sync key to a synchronization partner requesting to 
synchronize to some checkpoint. An integer is used as 
the sync key. When the sent sync key is zero the syn- 
chronization partner perfomns an initial synchronization. 
When the sent sync key is a value other than zero, the 



synchronization partner attempts to synchronize to the 
desired state. The value of the sync key is incremented 
only upon successful synchronization. A sync server 
can also include a sync key with change update notifi- 
cations sent to a sync client, which the client can use to 
detemine if the update notification is a valid update from 
the current sync state or is a delayed and obsolete up- 
date that should be discarded. 
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Description 

Field of the Invention 

[0001] The present invention relates generally to 
computer software, and more particularly to synchroni- 
zation of data. 

Background of the Invention 

[0002] Computing devices may store data in more 
than one place. When the same or related information 
is stored in two places, it Is possible for the data to 
change In one location (store) and not in another. Syn- 
chronization methods have been developed to propa- 
gate the changes between the different stores, so that 
the infomnation in the different stores correlate to each 
other 

[0003] In one method, during synchronization, chang- 
es to the data in the different stores are collected, com- 
pared, and reconciled. The synchronization process it- 
self involves making changes ("sync changes") to the 
data stores in order to "update" or propagate the chang- 
es made in other stores. AH of the required changes to 
synchronize the stores may not be completed during 
each synchronization attempt. For example, a connec- 
tion between stores may be broken during the process 
causing the synchronization attempt to be incomplete. 
One store, however, may indicate that synchronization 
has completed successfully when in fact the synchroni- 
zation was unsuccessful. 

[0004] In another method, changes are sent incre- 
mentally between the stores using notifications as the 
changes occur. Some implementations utilize both of 
these methods together. 

Summary of the Invention 

[0005] The present invention is directed at providing 
a system and method for synchronizing data stores. On 
each synchronization update, the syncing entities at- 
tempt to update each other up to the state at the time of 
the sync request is processed. This time or state is re- 
ferred to as the synchronization checkpoint ("sync 
checkpoint"). According to one aspect of the invention, 
each of these checkpoints is given a unique synchroni- 
zation key ("sync key") to represent the checkpoint 
state. 

[0006] According to one aspect of the invention, a 
sync initiator sends the sync key that it received in re- 
sponse to the last successful synchronization to the syn- 
chronization partner. If the receiving partner receives a 
valid sync key from the sender then the receiver re- 
sponds to the client's request. Otherwise, the receiver 
responds to the sender as appropriate. For example, the 
receiver could reply to the sender indicating that the 
sync key is not valid. 

[0007] According to another aspect of the Invention, 



the sync key is an integer that begins at zero and is in- 
cremented with each sync attempt that is successfully 
completed. The synchronization initiator (the sender of 
the synchronization request) determines the value of its 
5 sync key, which is based on its last synchronization at- 
tempt. The sync key is Incremented only upon the suc- 
cessful receipt and processing of the last sync re- 
sponse. 

[0008] According to yet another aspect of the present 

10 invention, a sync initiator can sync to a new checkpoint, 
resync from the last checkpoint, or initiate a completely 
new sync from scratch. For example, if N is the sync key 
value from the last successful sync, the sync initiator 
may send a sync key value of Nto indicate that it re- 
15 ceived the sync response for the last sync and wishes 
to sync from that checkpoint to the current state. If the 
sync Initiator sends a request with sync key =N-1 , the 
sync partner determines that the sync initiator did not 
receive a response to its last sync request or othenvise 
20 wishes to resync again from the last successfully proc- 
essed sync state. 

Brief Description of the Drawings 

25 [0009] 

FIGURE 1 isafunctional block diagram of one com- 
puting device adapted to implement one embodi- 
ment of the invention; 
30 FIGURE 2 illustrates a mobile computing device 
that may be used In one exemplary embodiment of 
the present invention; 

FIGURE 3 is a functional block diagram of one ex- 
emplary synchronization system as implemented 
35 using the computer device shown in FIGURE 1 and 
the mobile computing device shown in FIGURE 2; 
FIGURE 4 is a table illustrating exemplary synchro- 
nization steps; 

FIGURE 5 is an overview flowchart illustrating syn- 
40 chronization; 

FIGURE 6 shows a logical flow for preparing a syn- 
chronization request according to one embodiment 

of the invention; 

FIGURE 7 illustrates a logical flow for processing a 
45 received sync key; 

FIGURE 8 illustrates a logical flow for when a syn- 
chronization key relating to the client is not located; 
and 

FIGURE 9 illustrates a logical flow for perfonning a 
50 synchronization based on the sync keys. 

Detailed Description of the Preferred Embodiment 

[0010] The present invention is directed at providing 
55 a method and system for synchronizing data. Briefly de- 
scribed, a synchronization key indicating a synchroni- 
zation checkpoint is sent by a synchronization initiator 
to a synchronization partner. If the synchronization key 
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received by the synchronization partner is valid, the 
partner returns synchronization data to the initiator to 
synchronize the stores between the initiator and partner. 
[0011] Referring to FIGURE 1 , an exemplary system 
for implementing the invention includes a computing de- 
vice, such as computing device 100. In a basic config- 
uration, computing device 1 00 typically includes at least 
one processing unit 102 and system memory 104. De- 
pending on the exact configuration and type of comput- 
ing device, system memory 104 may be volatile (such 
as RAM), non-volatile (such as ROM, flash memory, and 
the like) or some combination of the two. System mem- 
ory 1 04 typically includes an operating system 1 05, one 
or more program modules 106, and may include pro- 
gram data 107. This basic configuration is illustrated in 
Figure 1 by those components within dashed line 108. 
[001 2] Computing device 1 00 may also have addition- 
al features or functionality. For example, computing de- 
vice 1 00 may also include additional data storage de- 
vices (removable and/or non-removable) such as, for 
example, magnetic disks, optical disks, or tape. Such 
additional storage is illustrated in Figure 1 by removable 
storage 109 and non-removable storage 110. Computer 
storage media may include volatile and non-volatile, re- 
movable and non-removable media Implemented in any 
method or technology for storage of infonnation, such 
as computer readable Instructions, data structures, pro- 
gram modules or other data. System memory 104, re- 
movable storage 109 and non-removable storage 110 
are all examples of computer storage media. Computer 
storage media includes, but is not limited to, RAM, ROM, 
EEPROM, flash memory or other memory technology, 
CD-ROM, digital versatile disks (DVD) or other optical 
storage, magnetic cassettes, magnetic tape, magnetic 
disk storage or other magnetic storage devices, or any 
other medium which can be used to store the desired 
infonnation and which can be accessed by computing 
device 100. Any such computer storage media may be 
part of device 100. Computing device 100 may also 
have input device(s) 11 2 such as keyboard, mouse, pen, 
voice input device, touch input device, etc. Output de- 
vice(s) 1 1 4 such as a display, speakers, printer, etc. may 
also be included. All these devices are known in the art 
and need not be discussed at length here. 
[0013] Computing device 100 also contains commu- 
nications connection(s) 116 that allow the device to 
communicate with other computing devices 118, such 
as over a network. Communications connection(s) 116 
is an example of communication media. Communication 
media typically embodies computer readable instruc- 
tions, data structures, program modules or other data in 
a modulated data signal such as a carrier wave or other 
transport mechanism and includes any information de- 
livery media. The term "modulated data signal" means 
a signal that has one or more of its characteristics set 
or changed In such a manner as to encode information 
in the signal. Byway of example, and not limitation, com- 
munication media includes wired media such as a wired 



network or direct-wired connection, and wireless media 
such as acoustic, RF, infrared and other wireless media. 
The terni computer readable media as used herein in- 
cludes both storage media and communication media. 

5 [0014] FIGURE 2 illustrates a mobile computing de- 
vice that may be used In one exemplary embodiment of 
the present invention. With reference to Figure 2, one 
exemplary system for implementing the invention in- 
cludes a mobile computing device, such as mobile com- 

10 puting device 200. The mobile computing device 200 
has a processor 260, a memory 262, a display 228, and 
a keypad 232. The memory 262 generally includes both 
volatile memory (e.g., RAM) and non-volatile memory 
(e.g., ROM, Flash Memory, orthe like). Themobllecom- 

15 puting device 200 includes an operating system 264, 
such as the Windows CE operating system from Micro- 
soft Corporation or other operating system, which is res- 
ident in the memory 262 and executes on the processor 
260. The keypad 232 may be a push button numeric di- 

20 aling pad (such as on a typical telephone), a multi-key 
keyboard (such as a conventional keyboard). The dis- 
play 228 may be a liquid crystal display, or any other 
type of display commonly used in mobile computing de- 
vices. The display 228 may be touch sensitive, and 

25 would then also act as an input device. 

[0015] One or more application programs 266 are 
loaded into memory 262 and run on the operating sys- 
tem 264. Examples of application programs include 
phone dialer programs, email programs, scheduling 

30 programs, PIM (personal infonnation management) 
programs, word processing programs, spreadsheet pro- 
grams, Internet browser programs, and so forth. The 
mobile computing device 200 also includes non-volatile 
storage 268 within the memory 262. The non-volatile 

35 Storage 268 may be used to store persistent information 
which should not be lost If the mobile computing device 
200 is powered down. The applications 266 may use 
and store information in the storage 268, such as e-mail 
or other messages used by an e-mail application, con- 

40 tact information used by a PIM, appointment information 
used by a scheduling program, documents used by a 
word processing application, and the like. A synchroni- 
zation application also resides on the mobile computing 
device 200 and is programmed to interact with a corre- 

45 spending synchronization application resident on a host 
or server computer to keep the information stored in the 
storage 268 synchronized with corresponding informa- 
tion stored at the host computer. 
[0016] The mobile computing device 200 has a power 

50 supply 270, which may be Implemented as one or more 
batteries. The power supply 270 might further include 
an external power source, such as an AC adapter or a 
powered docking cradle that supplements or recharges 
the batteries. 

55 [0017] The mobile computing device 200 is shown 
with two types of external notification mechanisms: an 
LED 240 and an audio interface 274. These devices 
may be directly coupled to the power supply 270 so that 
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when activated, they remain on for a duration dictated 
by the notification nnechanism even though the proces- 
sor 260 and other components might shut down to con- 
serve battery power. The LED 240 may be programmed 
to remain on indefinitely until the user tal<es action to 
indicate the powered-on status of the device. The audio 
interface 274 is used to provide audible signals to and 
receive audible signals from the user. For example, the 
audio interface 274 may be coupled to a speaker for pro- 
viding audible output and to a microphone for receiving 
audible input, such as to facilitate a telephone conver- 
sation. 

[0018] The mobile computing device 200 also in- 
cludes a radio interface layer 272 that performs the func- 
tion of transmitting and receiving communications, such 
as radio frequency communications. The radio interface 
layer 272 facilitates wireless connectivity between the 
mobile computing device 200 and the outside world, via 
a communications carrier or service provider. Transmis- 
sions to and from the radio interface layer 272 are con- 
ducted under control of the operating system 264. In oth- 
er words, communications received by the radio inter- 
face layer 272 may be disseminated to application pro- 
grams 266 via the operating system 264, and vice versa. 
[0019] FIGURE 3 is a functional block diagram gen- 
erally illustrating one embodiment for a synchronization 
system 300 for synchronization between a fixed com- 
puting device, such as an information server 310 and a 
mobile device 320, in accordance with the present in- 
vention. In this implementation, the information server 
310 Is a computing device such as the one described 
above in conjunction with Figure 1 , and the mobile de- 
vice 320 is a mobile computing device such as the one 
described above in conjunction with FIGURE 2. A syn- 
chronization application 342 performs the synchroniza- 
tion process between the information server 31 0 and the 
mobile device 320. In the embodiment illustrated, the 
synchronization application 342 is resident on a syn- 
chronization server 340, which is a computing device as 
described above in conjunction with Figure 1 . Typically, 
a firewall (not shown) is located between the synchro- 
nization server 340 and the information server 310 to 
protect data that is accessible to the information server 
31 0. In another embodiment, the synchronization appli- 
cation 342 may reside on information server 310. 
[0020] The mobile device 320 maintains mobile data 
322 locally in its storage 268 (shown in FIGURE 2). As 
mentioned earlier, the mobile data 322 may include e- 
mail or other messages used by an e-mail application, 
contact Infonnation used by a PIM, appointment infor- 
mation used by a scheduling program, and the like. The 
mobile device 320 may change the mobile data 322 at 
anytime. Once the mobile data 322 Is changed, server 
data 312 accessible by the infomnation server 310 will 
not have correlating information until a successful syn- 
chronization occurs. Similarly, the Information server 
31 0 may change the server data 31 2, such as through 
any number of networked personal computers (not 



shown) connected to the infonnation server 31 0. Again, 
once the server data 312 is changed, the mobile data 
322 and server data 312 no longer correlate (i.e., data 
is not synchronized). In order for the mobile data 322 

5 and the server data 31 2 to correlate (I.e. , synchronized), 
the mobile device 320 initiates a synchronization ses- 
sion. The synchronization application 342 saves infor- 
mation regarding the synchronization sessions in a syn- 
chronization state table 344. 

10 [0021] Briefly, in the synchronization session, syn- 
chronization data is transmitted between the mobile de- 
vice 320 and the information server 310 using wireless 
technology. The synchronization data includes mani- 
fests 324 sent by the mobile device 320 and incremental 

^5 updates 326 sent by synchronization application 342 to 
the mobile device. The incremental updates specify 
changes to the server data 31 2 since the last successful 
synchronization. 

[0022] FIGURE 4 is illustrates exemplary synchroni- 

20 zation steps. At step 1 , a synchronization initiator, such 
as a client, prepares an initial sync key and sends the 
sync key to a synchronization partner, such as a syn- 
chronization server. The server processes the received 
sync key at step 2. At step 3, the server returns the syn- 

25 chronization data to the client at step 3 at which point 
the client receives the synchronization data. After a suc- 
cessful synchronization, the client updates the synchro- 
nization key to reflect the successful synchronization. At 
some point in time after an initial synchronization, the 

30 client typically sends a synchronization request to the 
serverto sync to a new sync checkpoint. In other words, 
the client requests to receive all data not synchronized 
since the last successful synchronization between the 
client and server. 

35 [0023] Steps 4-8 illustrate two different synchroniza- 
tion attempts. At step 4 the client sends the last suc- 
cessful sync key indicating to the server to send chang- 
es in the data since the last successful synchronization. 
The server receives the request (step 4), processes the 

40 request (step 5) and returns the changed data to the cli- 
ent. In this particular example, the client receives all up- 
dates that have occun-ed after the initial synchronization 
between the client and server. The client receives the 
data and updates its data store. 

45 [0024] Similarly, at step 7 the client requests to syn- 
chronize to include updates since the last successful 
synchronization. In this particular example, the last suc- 
cessful synchronization was requested at step 4. At step 
8 the server processes the synchronization request from 

50 the client. In this particular example, the server sends 
the updates to the client, but all of the data does not 
reach the client. The server believes the client has been 
synchronized and updates its synchronization key, re- 
sulting in the client and server having the same valued 

55 synchronization key. 

[0025] Steps 9 and 10 illustrate a client requesting to 
synchronize to a checkpoint that the sen/er believes that 
the client has already been synchronized. At step 9, the 
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client requests a synchronization from the same state 
as requested at step 7. The server receives the request 
(step 9) and recognizes that the last synchronization re- 
quest was not successful for the client. The server, 
therefore, returns the updated entries to the client from 
the time of the sync checkpoint corresponding the syn- 
chronization key sent by the client. 
[0026] FIGURE 5 is an overview flowchart illustrating 
synchronization. At a start block, a synchronization 
process is Initiated. The synchronization can be initiated 
by any of the synchronization partners. According to one 
embodiment of the present Invention, a client desires to 
synchronize with a server. At a block 510, the client, or 
synchronization initiator, prepares for synchronization 
with the synchronization partner ("server"). (See FIG- 
URE 6 and related discussion). Successful synchroni- 
zation brings the state of the data stores on the client 
and server to the same state at a specific synchroniza- 
tion checkpoint. Moving to a block 520, the synchroni- 
zation is perfonned. Generally, the server sends data to 
the client containing all updates from the requested syn- 
chronization state to the current state of the server. The 
data may be sent to the client using many different meth- 
ods, as is well known to those of ordinary skill In the art. 
At a decision block 530, a determination is made as to 
whether the synchronization is successful. A successful 
synchronization for a client means that the synchroni- 
zation data received by the client was processed appro- 
priately. A successful synchronization for a server 
means that the server believes that all of the synchroni- 
zation data has been sent to the client. If the sync is not 
successful, the logical flow ends. If the sync Is success- 
ful, the logical flow moves to a block 540 at which point 
the sync key stored on the client and server is updated 
to reflect the successful synchronization. The logical 
flow then ends. 

[0027] FIGURE 6 shows a logical flow for preparing 
for synchronization according to one embodiment of the 
invention. Starting at a block 610, a client prepares a 
synchronization manifest. According to one embodi- 
ment of the invention, a synchronization manifest In- 
cludes identifying information about the client and a syn- 
chronization key. The synchronization key includes in- 
formation indicating what checkpoint the client desires 
to synchronize from with the server. The synchroniza- 
tion key can be thought of as a synchronization attempt 
identifier. According to one embodiment of the invention, 
the sync key is an integer that starts at a value of minus 
one, and Is incremented with each synchronization that 
is successful. Many other types of sync keys can be 
used. For example, the sync key could be a bit(s), float, 
character, and the like. Moving to a block 620, the client, 
or synchronization initiator, sends the manifest including 
the sync key to a synchronization partner, or server. The 
synchronization server receives the sync key and sends 
the client the requested synchronization data or an error 
message depending on the manifest and sync key re- 
ceived from the client (block 630) (See FIGURE 7 and 



related discussion). Flowing to a block 640, the client 
receives the data and processes the data. The logical 
flow then ends. 

[0028] FIGURE 7 illustrates a logical flow for process- 

5 ing a received sync key from a synchronization partner. 
Starting at a block 710, a synchronization server deter- 
mines the last synchronization key associated with the 
client requesting synchronization. According to one em- 
bodiment of the present invention, the synchronization 

10 server searches for the synchronization key associated 
with the requesting synchronization client. Decision 
block 720 determines if the synchronization key for the 
client is located. If a synchronization key is not located 
for the client, the client is synchronized with no memory 

15 of a prior synchronization (block 730) (See FIGURE 8 
and related discussion). If a synchronization key relating 
to the client is located, then the logical flow moves to a 
block 740, at which point the server compares the locat- 
ed synchronization key to the synchronization key sent 

20 by theclient (See FIGURE 9 and related discussion) and 
responds appropriately. 

[0029] FIGURE 8 Illustrates a logical flow for when a 
synchronization key relating to the client Is not located. 
Starting at a decision block 81 0, a determination is made 

25 as to whether this is the first, or initial, synchronization 
between the client and server. According to one embod- 
iment of the invention, an initial synchronization is indi- 
cated by a sent sync key value of zero. If this Is an initial 
synchronization, the logical flow moves to a block 820 

30 at which point an initial synchronization is performed. 
An Initial synchronization updates the client with all of 
the Initial Information stored on the server for the client. 
In other words, a synchronization is performed from 
scratch. If this is not an initial synchronization, the logical 

35 flow moves to a block 830 at which point an error mes- 
sage is returned. An error message indicates that a syn- 
chronization key should exist on the server, but that 
some error has caused the synchronization information 
to be lost for the client. The logical flow then ends. 

40 [0030] FIGURE 9 illustrates a logical flow for synchro- 
nization when a synchronization key related to the client 
is located. Starting with a start block and moving to a 
decision block 910, a detemnination is made as to 
whether a re-synchronization is requested. According to 

45 one embodiment of the invention, a resync is requested 
If the value of the sync key Is zero. If the client is re- 
questing a re-synchronization, the logical flow moves to 
a block 915. At a block 915, synchronization from an 
initial condition is performed. A re-synchronize request 

50 may occur in many different situations. For example, if 
thememory of the client was erased, or the client device 
was replaced with another similar device, such as when 
a device is upgraded. According to one embodiment of 
the Invention, the client and server perfonn a re-syn- 

55 chronization as if the request was an Initial synchroni- 
zation request. The logical flow then ends. 
[0031] When a re-synchronization is not requested, 
the logical flow moves to a decision block 920. At a de- 
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cision block 920, a determination is made as to whether 
this is the next expected synchronization request. For 
exannple, an expected synchronization request occurs 
when the server receives a synchronization key Indicat- 
ing that the last synchronization was successfully per- 
fomried. According to one particular embodiment of the 
invention, the expected synchronization key has a value 
of the server's synchronization key. For example, if the 
server's sync key has a value of 2, then the received 
value of the sent sync key would be 2. According to an- 
other embodiment, the expected synchronization key 
has a value of the server's synchronization key for the 
client plus one. For example, if the server's sync key has 
a value of 2, then the received value of the sent sync 
key would be 3. If this is the next synchronization re- 
quest, the logical flow moves to a block 925, at which 
point the next synchronization is performed. The server 
returns data from the point of the last synchronization 
checkpoint to the current checkpoint. The logical flow 
then ends. 

[0032] If the request is not for the next synchroniza- 
tion, the logical flow moves to a decision block 930. De- 
cision block 930 determines whether the last synchro- 
nization was successful. If the synchronization was not 
successful, the logical flow moves to a block 935. Ac- 
cording to one embodiment of the present invention, the 
received sync key value would be less than the server's 
sync key. In this situation, the server believes that a suc- 
cessful synchronization occurred forthe last synchroni- 
zation request from the client, but the client did not suc- 
cessfully synchronize to the last checkpoint. This situa- 
tion can occur under many different scenarios. For ex- 
ample, data sent by the server may never have reached 
the client, or the client may not have properly processed 
the data. At a block 935 the client Is synchronized to the 
current state of the server including the infonmation on 
the server from the checkpoint of the last successful 
synchronization as indicated by the client. 
[0033] If the last successful synchronization was suc- 
cessful, the logical flow moves to a decision block 940 
that determines whether the sent synchronization key is 
out-of-date. According to one embodiment of the 
present invention, if the synchronization key is more 
than one requested synchronization state from the serv- 
er's located synchronization key the synchronization 
key Is out-of-date. For example, If the sent sync key has 
a value of 1 , and the server has a sync key for the client 
having a value of 5 then the sync key is out-of-date. Sim- 
ilarly, if the received sync key has a value of 4, and the 
server has a sync key value of 2, the sync key is out-of- 
date. If thesynchronization key Is out-of-date, the logical 
flow moves to a block 945. According to one embodi- 
ment of the present Invention, an error is returned to the 
client indicating that an improper synchronization key 
was received (block 945). According to another embod- 
iment of the present Invention, the server returns syn- 
chronization data from the synchronization checkpoint 
as indicated by the sent sync key. For example, suppose 



that five synchronizations have successfully occurred 
between the client and server. Under this example, the 
server may store all synchronization checkpoints and 
synchronize from any of the five checkpoints. Iftheclient 
5 requests to synchronize with the server from state three, 
the server will send the data to the client checkpoint 
three to the current state to the client. Othenwise, the 
logical flow ends. 

[0034] The above specification, examples and data 
10 provide a complete description of the manufacture and - 
use of the composition of the Invention . Since many em- 
bodiments of the invention can be made without depart- 
ing from the spirit and scope of the Invention, the inven- 
tion resides in the claims hereinafter appended, 

15 

Claims 

1 . A method for synchronization, comprising: 

20 

(a) a synchronization initiator sending a sync 
key to a synchronization partner; 

(b) determining a desired synchronization state 
to synchronize from based on the sent sync 

25 key; and 

(c) the partner detennining if the sent sync key 
Is valid, and if the sync key is valid: 

(i) attempting to synchronize with the initi- 
30 ator f rom the desired synchron Ization state 

to a current state; and 

(ii) determining if the attempted synchroni- 
zation was successful. 

35 2. The method of Claim 1 , wherein detemilning the de- 
sired synchronization state to synchronize from 
based on the sent sync key, further comprises: 

(a) determining a value of the sent sync key; 
40 and 

(b) setting the desired synchronization state 
based on the value of the sent sync key. 

3. The method of Claim 2, wherein determining if the 
45 sent sync key is valid further comprises determining 

if a partner sync key exists related to the sent sync 
key; and if so: 

(a) determining a previously stored value of the 
50 partner sync key; and 

(b) comparing the value of the partner sync key 
to the value of the sent sync key. 

4. The method of Claim 3, wherein setting the desired 
55 synchronization state based on the value of the sent 

sync key, further comprises: 

(a) detennining if the desired synchronization 
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state is an initial synchronization state based 
on the value of the sent sync key; and 
(b) determining If the desired synchronization 
state is another valid synchronization state 
based on the value of the sent sync key, 

5. The method of Claim 3, wherein determining if the 
attempted synchronization was successful, further 
comprises: 

(a) the synchronization initiator determining if 
the synchronization was successful, and If so: 

updating the sync key on the initiator; and 

(b) the synchronization partner determining if 
the synchronization was successful, and if so: 

updating the partner sync key. 

6. The method of Claim 5, wherein determining if the 
desired synchronization state is another valid syn- 
chronization state based on the value of the sent 
sync key, further comprises, determining if the value 
of the sent sync key corresponds to a stored syn- 
chronization checkpoint. 

7. The method of Claim 6, wherein the sent sync key 
is an integer and the partner sync key is an Integer. 

8. A computer-readable medium having computer-ex- 
ecutable instructions for synchronization, compris- 
ing: 

(a) a client sending a sync key to a server; 

(b) determining a desired synchronization state 
from the sent sync key; and 

(c) attempting to synchronize with the client to 
the desired synchronization state. 

9. The computer-readable medium of Claim 8, further 
comprising: 

(a) determining If the attempted synchroniza- 
tion was successful; and 

(b) updating the value of the sent sync key if 
the synchronization was successful. 

10. The computer-readable medium of Claim 9, where- 
in determining the desired synchronization state 
from the sent sync key, further comprises: 

(a) determining a value of the sent sync key; 

(b) locating a server sync key having a value; 

(c) comparing the value of the sent sync key to 
the value of the server sync key; and 

(d) setting the desired synchronization state 
based on the comparison. 



11. The computer-readable medium of Claim 10, 
wherein setting the desired synchronization state 
based on comparison, further comprises: 

5 (a) setting the desired synchronization state to 

an initial synchronization when the value of the 
sent sync key is zero; or 
(b) setting the desired synchronization state to 
a stored synchronization state of the server 

10 when the comparison detennines that the value 

of the sent key relates to a stored synchroniza- 
tion state.. 

12. The computer-readable medium of Claim 11, 
15 wherein detennining if the attempted synchroniza- 
tion was successful, further comprises: 

(a) the client determining if the synchronization 
was successful, and if so: 

20 

updating the value of the sent sync key; 
and 

(b) the server determining if the synchroniza- 
25 tion was successful, and if so: 

updating the value of the server sync key. 

13. The computer-readable medium of Claim 12, 
30 wherein updating the value of the sent sync key and 

updating the value of the server sync key, further 
comprises incrementing the value of the sync key 
stored on the client and the server sync key. 

35 14. A system for synchronizing data, comprising: 

(a) a processor and a computer-readable me- 
dium; 

(b) an operating environment stored on the 
40 computer-readable medium and executing on 

the processor; 

(c) a communication connection device operat- 
ing under the control of the operating environ- 
ment; and 

45 (d) a synchronization device operating under 

the control of the operating environment and 
operative to perform actions, including: 

(i) receiving or sending a sync key to a syn- 
50 chronization partner; 

(ii) determining a desired synchronization 
state from the sync key; 

(iii) synchronizing with the client from the 
desired synchronization state to a current 

55 state; and 

(iv) determining If the synchronization was 
successful. 



7 



13 EP1 271 320 A1 

1 5. The system of Claim 8, further comprising updating 
the sync key if the synchronization was successful. 

16. The system of Claim 15, wherein determining the 
desired synchronization state from the sync key, fur- s 
ther comprises: 

(a) determining a value of the sync key; 

(b) setting the desired synchronization state 
based on the value of the sync key. 

17. The system of Claim 16, wherein detenmining If the 
attempted synchronization was successful, further 
comprises determining If the synchronized data 
was processed, and if so updating the value of the '5 
sent sync key. 
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